I'll have time to take a look at this over the weekend

great, please note my PR testing case for json serialization of form is broken. I am sending you the diff to understand how you want to approach form serialization as form contains multiple elements

@acivitillo, I've done a proper rebase with main and fixed up the serialization implementation. My understanding of how the elements attribute worked was a bit off. Also, here's some updated sample code for testing this out:

from idom import component, event, html, run


@component
def Form():

    @event(prevent_default=True)
    def handle_form(event):
        print(event["target"]["elements"])

    return html.form(
        {"onSubmit": handle_form},
        html.input({"name": "firstname"}),
        html.p("test"),
        html.button({"type": "submit", "value": "Submit"}, "Submit"),
        html.input({"lastname": "lastname"}),
        html.p("tes2t"),
    )


run(Form)

Note the prevent_default=True. Otherwise the page adds query parameters to the URL. IDOM interprets query parameters as keyword arguments to the root component. Not sure if that behavior should be removed when routing is introduced (cc: @Archmonger)?

Also, I changed html.input({"name": "name"}) to html.input({"name": "firstname"}), because child elements of a <form> get bound as attributes of that <form> under their name. Thus, attaching a form <input> name="name" caused a serialization issue which I handle (and note in a comment).

Could you address the tests given these changes? In addition to the elements attribute, I've serialized the name attribute too.

Serializing form attributes into the URL would be a nice feature if we could get it working cleanly. Might help with form value persistence upon WS disconnect?

We should do some investigation later down the line to figure out what React apps typically do for forms.

To properly handle form URLs we'll need a wrapper around the standard form element. Besides that, this PR works.

What do we plan on doing about file fields

Not entirely sure. We can address #574 in a different PR though.